I was trying to get a PR together, but was hitting validation issues. This is what I wrote:

+++ b/apis/v1alpha2/httproute_types.go
@@ -343,12 +343,19 @@ type HTTPHeaderMatch struct {
        // Name is the name of the HTTP Header to be matched. Name matching MUST be
        // case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).
        //
-       // If multiple entries specify equivalent header names, only the first entry
-       // with an equivalent name MUST be considered for a match. Subsequent
+       // If multiple entries specify equivalent header names, only the first
+       // entry with an equivalent name MUST be considered for a match. Subsequent
        // entries with an equivalent header name MUST be ignored. Due to the
        // case-insensitivity of header names, "foo" and "Foo" are considered
        // equivalent.
        //
+       // When a header is repeated in an HTTP request, it is
+       // implementation-specific behavior as to how this is represented.
+       // Generally, proxies should follow the guidance from the RFC:
+       // https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding
+       // processing a repeated header values as a single comma (",")
+       // separated header, with special handling for "Set-Cookie".
+       //
        // +kubebuilder:validation:MinLength=1
        // +kubebuilder:validation:MaxLength=256
        Name string `json:"name"`

If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored.

I think that interpretation would run into the same vulnerability that Envoy ran into:

Attackers can set multiple values of a non-inline header, e.g. x-foo: bar and x-foo: baz. Affected Envoy components will only observe the first value, x-foo: bar, in matchers, but both x-foo: bar and x-foo: baz will be forwarded to upstreams. Upstreams may take both values into consideration, resulting in an inconsistency between Envoy’s request matching and the upstream view of the request.

An example of how this might be exploited is if an Envoy filter validates both x-request-credential and x-request-scope headers, checking whether the given credentials match the request scopes. Only the first scope header would be validated, but the upstream may interpret all provided scopes as being valid.

For reference, their fix involved changing matching to use a comma separated list of header values, which seems like an appropriate requirement here: https://github.com/envoyproxy/envoy/blob/a12869fa9e9add4301a700978d5489e6a0cc0526/docs/root/version_history/v1.14.5.rst

I think we have two things, maybe want to clarify more:

1. multiple HTTPHeaderMatch entries (which is what the first thing is talking about)
2. multiple of the same header in the HTTP request -- which is somewhat malformed except for the comma ones; and the handling of those is up to the implementation. Good secure implementations merge header together using commas and drop extra headers for fields that don't support commas etc and Set-Cookie is an odd duck.

That makes a lot of sense, I was confusing the two. Agree with your suggested updates given that distinction.

Subsequent entries with an equivalent header name MUST be ignored.

So.. is someone going to change envoy to match like this or are we all just going to be non-compliant 🙂

I think our spec should actually more closely match the updated envoy behavior to avoid the vulnerability they ran into (referenced in comment above).